FedRAMP Gatekeeper can reject pods that fall back to the default service account. TidbInitializer creates a Job pod directly, so the CRD needs an explicit field that users can bind to a dedicated ServiceAccount without carrying operator-side patches.

The initializer spec now exposes serviceAccountName and passes it through to the generated Job pod template. The CRD and OpenAPI schema are updated so users can configure the field through the v1 API.

Constraint: FedRAMP block-default-service-account policy rejects implicit default service account usage
Rejected: Hardcode tidb-initializer in the manager | forces one service account name on all users and keeps requiring operator code patches
Confidence: high
Scope-risk: narrow
Directive: Keep this field as a pass-through to the Job pod spec; do not add defaulting here without checking backward compatibility
Tested: go test ./pkg/manager/member
Tested: cd pkg/apis && go test ./pingcap/v1alpha1
Tested: git diff --check